从3月24日晚间到25日上午，有许多 iPhone 用户惊奇的发现，淘宝 APP 启动后随之被锁定在一个提示内测版本已过期的 Alert 面前，完全无法进入主界面使用。一时网上说法纷纭，甚至连“程序员报复写的 bug”的说法都冒了出来，但是笔者感觉创造这个说法的人可能连前后端都分不清楚，闲来无事就凭借目前有限的已知信息来推导一下问题可能出在哪儿。
这里我会用到一个思维工具叫做“黑箱”，当我们把某个看到了结果也了解了基础环境的事件看做一个对外只能看到输入和输出、中间处理过程不明的盒子的话，这个盒子就叫做黑箱。这种思维工具经常被用在一些推理和验证假设的情况中，如复现事件、案件调查等等。
那么，这里该如何用黑箱工具来推导问题根源呢？
已知结果，也就是“输出”部分——Output
a. iOS 客户端出问题了，Android没问题。
b. 不是版本更新之后出现的问题，而是线上版本。
c. 提示说3.28过期，本地时间改成3.28后悔提示已停用。
d. 官方的 hotfix 是快速关闭 alert 而非阻止其出现。
e. 到下午2点半为止依然没有完全修复，启动就闪退。
业界习惯，也就是“输入”部分——Input
z. MVC或者MVVM设计会在后台控制客户端的某些功能的开启和关闭。
y. 公司为了统计数据的准确性，时间等属性都会以应用服务器端为准。
x. 大公司都会有完善的代码审计、自动化测试与安全审计等环节。
推论：
- 程序员复仇论在代码审计环节就站不住脚，功能和意义不明的代码在 Review Meeting 上就会直接被干掉。
- 改了系统本地时间可以改变其提示，说明此组件对时间属性的权限是继承系统本身的，因为如果是APP自己的私有组件的话一定是会以服务器时间（至少以运营后台手动设定的时间）为准。
- 由12可以得到，这个组件应该是版本更新相关组件。而由「内测版本」等相关内容来看，很有可能是用了 testflight 的 SDK 并且被发布到线上了。这也可以解释为什么后续的修复措施都cover不住，因为按权限管理的设计这个组件的权限等级是要高于其他app内组件的（继承系统层级的权限）。
但为什么testflight这样一个用于定向发放内测资格的工具的组件会被发布到正式版本？按说最强迫症和洁癖的选择应该是在需要做内测时纳入SDK然后发布，从后台进行对应版本的策略配置，测试通过后再剥离SDK清理冗余代码后进入正常的发布流程。但在敏捷开发大行其道的今天，这样做会明显拖慢发布进度，所以合理推测是为了CI/CD的方便选择了合并性发布、选择性开启，也就是带SDK进入正式发布流程，但是是进入到beta分支还是stage-prod分支看是否有发布前内测的需要，而且进入prod分支后根据渠道号或内部版本号来关闭配置就可以了。曾经iOS还允许第三方更新组件存在的时候还有另外一个好处就是可以方便进行强制更新和紧急修复。
所以回头来看这次事故，原因有两种可能，一种可能是原本打算做内部新功能测试，但负责配置版本（或版本号）的运营人员粗心大意错误配置到了线上版本上；另一种可能是真的有人在搞事，那也还是版本管理运营与维护人员的责任了，因为只有这个岗位有对应的执行权限，但这种可能性极小，而且要负法律责任的哟朋友，影响一辈子的工作信誉的。问题是到现在为止线上都没有恢复正常，难道testflight 的配置是永久性生效的？还是说负责审核前面那个人的操作的直属主管休假去了……
但是肯定不是网传的聊天记录中“iOS 程序员小哥留下的隐藏 bug”——推论1已经说过了。
可能有伸手党大爷习惯性问一句——别说这些没用的，就告诉我怎么避免这种情况出现！
我们在对重大决策流程的确认环节一般会做防呆设计，比如重点内容的强调、二次或多次确认等，而为了对抗人的惯性思维和惯性动作也会衍生如错位设计（可选项每次出现时随机调换位置）之类的方案，但这些只适用于重要环节，如果你觉得所有环节都重要都要用上的话，恭喜你，你还得再吃几次别的亏才能克制住自己这些小聪明。
最后，在安全领域有一句话叫薄弱的环节永远都是人。各种产品的交互设计除了考虑人的「正向行为习惯」以外，也经常要在「对抗不良习惯」上做很多考虑，只是对于用户产品很多时候没有所谓的「不良习惯」，反倒会被产品经理借以七宗罪和人性的解释用于实现自己的利益目的。